Can we stay under 0.8.3? It's mainly fixes of the features 0.8.3 introduced.
Once we have significant new features or protocol support I'd move to 0.8.4.
This avoids us also from finding a new code name.

Yep, the only concern was this snippet:

#define EC_VERSION            "0.8.3.1"
#define EC_VERSION_MAJOR      0
#define EC_VERSION_MINOR      8
#define EC_VERSION_REVISION   3

so, based on git grep

src/ettercap.rc:#define RC_VERSION  EC_VERSION_MAJOR, EC_VERSION_MINOR, EC_VERSION_REVISION, 0

something on windows will still see the version as 0.8.3 without the .1 number.

I don't know, maybe we can do something like
#define EC_VERSION_SUBREVISION 1
and define it in ettercap.rc? @gvanem what do you think?

this is what I meant
b0dc99b

@eaescob is it possible to create a fingerprint.php page on the website?
b97d5b9
it should just save some parameters into a file, nothing difficult to do, if we have a php server!

   snprintf(getmsg, sizeof(getmsg), "POST %s?finger=%s&os=%s HTTP/1.1\r\n"
                                     "Host: %s\r\n"
                                     "Accept: */*\r\n"
                                     "User-Agent: %s (%s)\r\n"
                                     "\r\n", page, finger, os_encoded, host, EC_GBL_PROGRAM, EC_GBL_VERSION );

@eaescob is it possible to create a fingerprint.php page on the website?
b97d5b9
it should just save some parameters into a file, nothing difficult to do, if we have a php server!

   snprintf(getmsg, sizeof(getmsg), "POST %s?finger=%s&os=%s HTTP/1.1\r\n"
                                     "Host: %s\r\n"
                                     "Accept: */*\r\n"
                                     "User-Agent: %s (%s)\r\n"
                                     "\r\n", page, finger, os_encoded, host, EC_GBL_PROGRAM, EC_GBL_VERSION );

We'd need a database for fingerprints right? I can host it on one of my digitalocean VMs.

If you want to store the fingerprints database (a plaintext file is probably the best solution), we could also restore the automatic download of the updated db, removed in
47638bd

@eaescob I opened #1060 to track the update functionality, better don't include in this minor update

@eaescob I opened #1060 to track the update functionality, better don't include in this minor update

let's think about this for a second. Do we know if this feature is being used? Also, how do we feel about collecting TCP packet fingerprints? Not sure how much of a burden that can put us in.

Just tested. When I use the bundled curl, CURL_FOUND remains OFF and sslstrip plugin is not being built. Even though sslstrip is the main reason why the libcurl dependency is there.

@koeppea if you look at travis output, the plugin is there...
https://travis-ci.org/github/Ettercap/ettercap/jobs/708687562

what is your configuration for cmake?

what is your configuration for cmake?

Reproduced on two computers:

$ cmake -DCMAKE_BUILD_TYPE=Debug -DENABLE_IPV6=On -DSYSTEM_CURL=Off -DSYSTEM_LIBNET=Off ..

what is your configuration for cmake?

Reproduced on two computers:

$ cmake -DCMAKE_BUILD_TYPE=Debug -DENABLE_IPV6=On -DSYSTEM_CURL=Off -DSYSTEM_LIBNET=Off ..

I did the same, but the file is there...
can you please have a look?
http://paste.debian.net/1157398/

I'm trying on debian sid now

Same version on Debian minimal chroot without libcurl installed system-wide
http://paste.debian.net/1157400/
am I looking at the wrong plugin filename?

@eaescob I opened #1060 to track the update functionality, better don't include in this minor update

let's think about this for a second. Do we know if this feature is being used? Also, how do we feel about collecting TCP packet fingerprints? Not sure how much of a burden that can put us in.

I honestly don't know... we can have it disabled by default, test it internally and see what happens!

@LocutusOfBorg yes you're right. The build files are also present on my machine. But the plugin is not available for activation even though the library file is also present in the target library directory:

...
[0]      pptp_clear  1.0  PPTP: Tries to force cleartext tunnel
[0]        pptp_pap  1.0  PPTP: Forces PAP authentication
[0]      pptp_reneg  1.0  PPTP: Forces tunnel re-negotiation
[0]      rand_flood  1.0  Flood the LAN with random MAC addresses
[0]  remote_browser  1.2  Sends visited URLs to the browser
[0]       reply_arp  1.0  Simple arp responder
[0]    repoison_arp  1.0  Repoison after broadcast ARP
[0]   scan_poisoner  1.0  Actively search other poisoners
[0]  search_promisc  1.2  Search promisc NICs in the LAN
[0]       smb_clear  1.0  Tries to force SMB cleartext auth
[0]        smb_down  1.0  Tries to force SMB to not use NTLM2 key auth
[0]    smurf_attack  1.0  Run a smurf attack against specified hosts
[0]     stp_mangler  1.0  Become root of a switches spanning tree


Plugin name (0 to quit): sslstrip

FATAL: sslstrip plugin can not be found !

Closing text interface...


Terminating ettercap...
Unified sniffing was stopped.

koeppea@pinky:/usr/local/lib/ettercap$ ls -lh *sslstr*
-rwxr-xr-x 1 root staff 3,2M Jul 19 22:32 ec_sslstrip.so
koeppea@pinky:/usr/local/lib/ettercap$ 
koeppea@pinky:/usr/local/lib/ettercap$ 

Ah... here we go:

[     init]     plugin_load_single: /usr/local/lib/ettercap/ec_sslstrip.so
[     init]     plugin_load_single - /usr/local/lib/ettercap/ec_sslstrip.so - dlopen() | /usr/local/lib/ettercap/ec_sslstrip.so: undefined symbol: nghttp2_pack_settings_payload
[     init]     USER_MSG(): plugin ec_sslstrip.so cannot be loaded...

[     init]     plugin ec_sslstrip.so cannot be loaded...

Seems it requires a new dependency (BTW: which is also needed for the HTTP/2 support I'm currently working on).

ok, so this is something that is not yet in master, so a future problem, right?

so a future problem

Well it's apparently already depending on the new version of the bundled curl package that will come with this subrelease.
So I'd say we have to add this with 0.8.3.1. Maybe as an dependency with a asterisk.

Can you please try this one?
49973f6

ldd of the ec_sslstrip.so plugin now shows it...

ok I did find how to fix it, rebased and pushed

I put 20200801 as release date

@eaescob I took your commit on branch use-libcurl-fprint-submit, fixed typos, refactored on top of the new fixes, tested with a localhost server successfully and added to this branch as: 7065b66

@LocutusOfBorg Excellent! I wonder if we should refactor the whole fingerprint system completely to allow folks to configure the URL where they want ettercap to submit fingerprints to. Can we just noop it for now until we decide how to proceed with it?

@LocutusOfBorg Excellent! I wonder if we should refactor the whole fingerprint system completely to allow folks to configure the URL where they want ettercap to submit fingerprints to. Can we just noop it for now until we decide how to proceed with it?

I just did that, I also had to put the old implementation if the curl is not found, to avoid build failures when curl was not found, and plugins were disabled.

ok I did find how to fix it, rebased and pushed

Works. This was also what I've tested. Disabling HTTP/2 support at configure time. Did 49973f6 not work out?

ok I did find how to fix it, rebased and pushed

Works. This was also what I've tested. Disabling HTTP/2 support at configure time. Did 49973f6 not work out?

nope, looks like the ndghttp2 support was required to be inside libcurl.a, not outside, so linking the plugin with it, makes the loader fail when loading the static curl library.

As you said, we have to patch probably the curl library to make it work, something I don't really think its needed!

BTW I added a new commit, to not force-require curl for building plugins

Hi, Franky,

Who is doing the release on GitHub tomorrow?

How about the web site? Shall I take over something?

Is it OK to do tomorrow? I can do both no problem! My testing was good

I can make the website changes. What do we need to update with the new release? I can cut the tarball tomorrow

What do we need to update with the new release?

Well merge this PR, create a new Tag and Release, attach the tarball (I think it was only the source w/o the bundled_deps directory). Then update the Website.

This should be it. I guess you take care for the Debian bases Distros. I can write an email to Gentoo and Arch Linux Maintainers.

this is how I create a release:

# go in master branch
git checkout master
# get new changes
git fetch upstream 
# update local master branch
git merge upstream/master 
# create the tag
git tag v0.8.3.1
# push the tag
git push upstream v0.8.3.1

after you pushed the tag, the "tag" and tarball are created
https://github.com/Ettercap/ettercap/releases

so, I go there and click on the tag and "create a new release"
copy-paste from CHANGELOG file and from previous releases the legenda
download the tarball, and remove bundled_deps from inside, and reupload for people who needs it (e.g. Debian)

and click publish!

and congrats to you all for the release!